Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Attribute table

The ryc_attribute table has these fields:

attribute_label — This CHARACTER field is the name of the attribute. For SmartObject attributes, this is the same as the name in the property include files. For widget attributes, the name is normally the same as the 4GL attribute name (including hyphens, which are otherwise normally avoided in attribute names).
attribute_group_obj — This DECIMAL object ID points to the attribute group for the attribute.
data_type — This INTEGER field holds the data type of the attribute. As you will see in the description of the fields for the attribute_value table, Progress Dynamics supports a list of attribute data types corresponding to the native Progress data types, and stores the attribute value in a field of that data type. This field, therefore, identifies which of the attribute value fields actually holds the value for the attribute. Progress Dynamics Version 1 users might be aware that there was an ryc_attribute_type table in Progress Dynamics Version 1. This table has been removed, as the type was really nothing more than the data type, which is now stored here. This is an integer field for performance reasons. The valid values are as follows:
1 — Character
2 — Date
3 — Logical
4 — Integer
5 — Decimal
6 — Reserved
7 — Recid
8 — Raw
9 — Rowid
10 — Handle
11 — Memptr
12 — reserved
13 — reserved
14 — Com-handle

These values map to the values used in the 4GL and other OpenEdge tools.

attribute_narrative — This CHARACTER field provides a full description of the purpose and use of the attribute.
override_type — This CHARACTER field indicates whether the standard get and set functions must be used to set and retrieve the attribute value. Normally, these functions serve only to permit other application objects to access the properties of a SmartObject, and for access within the object itself and its super procedures, code can directly access the temp-table that holds the object’s attribute values. In that case, this field is blank. Other values this field can take are get, indicating the get function does something specific to retrieve the value and must be executed, set, indicating the set function must be executed to set the value, or get,set indicating both the get and the set functions must be executed. If this field has a value, then the functions to get and/or set this property need to be defined. The functions are executed instead of simply accessing the value directly in order to allow them to contain additional logic beyond simply retrieving the value from the temp-table. This is the equivalent of defining the xp preprocessors in the property include files of the ADM, but is more flexible in that it differentiates between get and set.

Note that in code that checks this value, a CAN-DO or LOOKUP should be used to ensure the order of the get,set pair is irrelevant.

runtime_only — This is a LOGICAL field that defaults to NO. If it is set to YES, then the value of this attribute should not be stored in the Repository and is only to be added to the attribute temp-table at run time without an initial default value. An example would be an attribute that stores a handle, as the handle has no context outside of the current session, but still needs to form part of the valid attribute list. Other examples are attributes that store the current state of an object, such as ObjectInitialized. There would be no point to assigning such attributes a default value. This field is useful in that it permits tools, such as the dynamic property sheet, to filter out attributes that it is not meaningful to assign a value to at design time.
is_private — This is a LOGICAL field that defaults to NO. If it is set to YES, then the value of this attribute is not intended to be accessed outside of the class where it is defined. This field is also used to filter out attributes from the dynamic property sheet and other tools. Generally, get and set functions are not defined for private attributes.
constant_level — This is a CHARACTER field and identifies the level at which a property can be modified. The valid values for this are class, indicating it can only be specified at the class level, master, indicating that the value can be modified at the master level, and blank, indicating that there are no restrictions on where the attribute can be assigned a value. This field also assists tools, such as the dynamic property sheet, in filtering out attributes from its display. An attribute, such as ObjectType, is defined once for the class and should not be changed in a master or instance. A master attribute, such as the ObjectName, should not be changed in an instance. Thus, the dynamic property sheet and other tools disable updates to attributes with a constant_level of class when you are defining a master or instance, and disable updates to attributes with a constant_level of master when you are defining instance attributes for an object in a container. There is also a constant_value field in the attribute_value table that is a LOGICAL indicating whether further modifications are allowed to the property. The attribute table’s constant_level field therefore affects how the constant_value flag is set in the attribute_value table.
derived_value — This is a LOGICAL field that defaults to NO. It can be set to YES to indicate that the property value is derived from other properties or other run-time information and doesn’t need to be defined in the attribute temp-table or stored in the Repository. Its value is therefore always set and retrieved using its get and set functions, which must contain the code needed to determine the value. As an example, the Visual class has three attributes that provide information derived from the getSysColor built-in function and the COLOR-TABLE 4GL object. These are called color3DFace, color3DHighight, and color3DShadow. Because the attribute values are always derived from this system function, there is no need to store the value in the attribute temp-table. Code must always use the get functions to retrieve the values.
lookup_type — This CHARACTER field defines the supported means of validating the attribute value for a specific object type. It is used in the dynamic property sheet to determine whether to overlay a combo box, a lookup button, or nothing at all on the attribute value field. Possible values are:
LIST — If the lookup_type is LIST, then the lookup_value field described next contains a string of possible attribute values in list-item-pairs format. In the property sheet, a combo box containing these values will overlay the attribute value field, so that the user must select one of the defined values for the attribute.
DIALOG — In this case, the lookup_value field contains the relative path and filename of a dialog container where the attribute value can be selected. In the property sheet, a lookup button will overlay the attribute value field. When the user selects the button, the specified dialog box is launched. The user can also enter a value directly without using the dialog.
DIALOG-R — This is like the DIALOG option, but makes the attribute value field read-only, forcing the use of the dialog box. This is necessary for dialog boxes that would return delimited lists that you would not want users to enter manually, or simply to control the value entered.
PROC — Here, the lookup_value field contains the relative path and filename of a procedure to execute to determine the list of valid attribute values in some special way. The Progress RETURN-VALUE of the procedure must contain a string of the list-item-pairs used to populate the combo box that overlays the attribute value field.
“” — Blank indicates a free text entry. The dynamic property sheet simply enables the browse cell in this case so that the user can enter a value.
lookup_value — This CHARACTER field can be used to specify a list of distinct values allowed for this attribute, or it can specify a procedure call that returns a list of values, or it can specify the name of a dialog box, as discussed in the description of lookup_type. When it contains a list, the delimiter must be CHR(3) rather than a comma, to allow for the possibility that a value might itself contain a comma. The value and format of the lookup_value field are dependent on the value of the lookup_type field, as follows:
If the lookup_type is blank, then the lookup_value field is blank. Here, there is no restriction on the value the user can enter, and also no assistance in choosing a value.
If the lookup_type = LIST, then the lookup_value specifies the LIST-ITEM-PAIRS values. This is a delimited list of labels and values in the form: label1,value1,llabel2,value2,...
If the lookup_type = DIALOG, then the lookup_value specifies the relative path and filename of the dialog box to be run from the property sheet. The dialog procedure must return two OUTPUT parameters, the first a LOGICAL indicating whether the property was changed, and the second a CHARACTER output parameter containing the value, for example, RUN colorChooser.w (OUTPUT lOK, OUTPUT cValue).
If the lookup_type = PROC, then the lookup_value field specifies the relative path and filename of an external procedure to be run from the property sheet at initialization, which returns a delimited list of list-item-pairs.
design_only — If this LOGICAL field is set to YES, then this attribute is only modifiable at design time, not at run time. The default is NO.
system_owned — If this LOGICAL field is set to YES, this attribute can only be modified by users with a system-owned flag in their privilege definition. Certain attributes are required for the application to function correctly, and these are set to system_owned to prevent accidental deletion. Only users classified as able to maintain system_owned information can manipulate this data. In many cases, the actual attribute label must match to a valid Progress-supported SmartObject property.